PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

} catch (URISyntaxException e) {
  LOG.log(Level.WARNING, "Could not strip credentials from URI", e);
}

PR Code Suggestions ✨

Explore these optional code suggestions:

-return new PasswordAuthentication(username, password.toCharArray());
+return new PasswordAuthentication(username, (password != null) ? password.toCharArray() : new char[0]);

-        this.config =
-            ClientConfig.defaultConfig()
-                .baseUri(
-                    new URI(
-                        config.baseUri().getScheme(),
-                        null,
-                        config.baseUri().getHost(),
-                        config.baseUri().getPort(),
-                        config.baseUri().getPath(),
-                        config.baseUri().getQuery(),
-                        config.baseUri().getFragment()));
+        config = config.baseUri(
+            new URI(
+                config.baseUri().getScheme(),
+                null,
+                config.baseUri().getHost(),
+                config.baseUri().getPort(),
+                config.baseUri().getPath(),
+                config.baseUri().getQuery(),
+                config.baseUri().getFragment()));

-this.config =
-    ClientConfig.defaultConfig()
-        .baseUri(
+this.config = new ClientConfig(config)
+    .baseUri(

@VietND96 Please do not merge this, in my mind this will not fix the issue.

@diemol sure
I also provided new tests for the bugfix, you can try run it locally
Unfortunately i am away from pc, so i can attach test results later today or tomorrow

Just wondering why @joerg1985 thinks this does not fix the issue.

@diemol i will write later this evening details about this and the original issue.

This PR does remove the UserInfo from the URI, this is okay, but it will not fix the issue #13803 from my point of view.

I have asked inside the ticket #13803 for details about the setup, but never did get a response. In #13802 you can see a nginx response with 404, so my current assumption is the authentication is done by a reverse proxy not following the RFC for WWW-Authenticate. The Java Authenticator will work only in case the server does send a 401 + challenge. https://datatracker.ietf.org/doc/html/rfc7235#section-4.1

We would need to translate the UserInfo from the URI to a 'Authorization' header and send it blind to the server. This might end in other issues, e.g. we do not know the expected scheme and might send the plain credentials (Basic scheme) instead of a hashed one (Digest scheme) over a unencrypted connection.

The nginx config might be an attemp to hide the service from attackers by forcing the clients to send the 'Authorization' header without a challenge. Some of the selenium language bindings might do so by default and IF it should be supported, this could be implemented in Java too. But this should be done via opt-in and not by default to avoid unexpected issues. And we should know the usecase so we can document this, to avoid more magic lines in the code nobody is aware of the use.

I would propalby hide the service using a UUID prefix in the path, the server has a command line flag to add a prefix...

@iampopovich, without this fix, for example a simple get started driver = new RemoteWebDriver("http://admin:password@localhost:4444/wd/hub", options);, does it work as of now?

@iampopovich, without this fix, for example a simple get started driver = new RemoteWebDriver("http://admin:password@localhost:4444/wd/hub", options);, does it work as of now?

Actually, this kind of embedded auth URL works in Python binding. In background, it also extract user:pass from url then Base64 encode it and set to request header Authorization. You can inspect code at

@iampopovich, without this fix, for example a simple get started driver = new RemoteWebDriver("http://admin:password@localhost:4444/wd/hub", options);, does it work as of now?

Looks like it works without this change, since I added a test to example site SeleniumHQ/seleniumhq.github.io#2131

@VietND96 What should we do next? Clearly, this PR does not fix the bug. I tried implementing authorization similar to the Python bindings client, but it didn’t solve the issue. At the moment, I don’t have enough knowledge to propose an alternative solution.

We can close this pull request for now, and perhaps I’ll revisit the problem later if it’s still relevant.